Industrial control systems can employ complex mechanical, electronic, electro-mechanical, and/or robotic machinery to perform various automated mechanical and/or electrical functions. Examples of machinery include industrial motors, pumps, conveyors, escalators, drills, refrigeration systems, and so forth. An industrial control system can utilize one or more control devices to activate or deactivate the machinery and/or to determine an appropriate level of activation for the machinery (e.g., an amount of current to supply to a variable input motor). Additionally, the control devices can be associated with logical program code that determines an appropriate time, degree, manner, and other criteria for operation of the machinery. For example, the determination can be based on various circumstances, including an output of another device, a reading of an optical sensor, an electronic measurement, a movement, a number of rotations of a device, and so on.
The machinery can be controlled by at least one industrial controller, such as, for example, programmable logic controllers. The industrial controllers can also communicate with higher level computing systems or servers that aggregate data from the controllers and help to manage day-to-day activities of an enterprise. As systems have become more complex, however, communications and functional cooperation between components of the industrial automation system has become a challenge. For instance, when users purchase multiple products from one or more vendors, there is often limited interoperability and consistency between such products. Software and control engineers must then learn each product and how the components interact with each other. Limited product and component consistency suggest that techniques engineers learn for one product do not necessarily carry over to other implementations.
Often, integration of products in the industrial automation system is complex and difficult to manage. Process and control engineers cannot easily code and configure their respective components without concern for other system components, which may have different manufacturers and different platforms.
Another problem with integration of products is that process and control engineers focus on underlying technical details, including implementation and glue logic, rather than the application level concerns, for example process information. For instance, an engineer may decide to automate a manual section of their plant. The design may start at a high level but soon becomes a series of discussions regarding nonfunctional requirements e.g., distributed component object model (DCOM), transmission control protocol (TCP), transaction rates, and the like. While these nonfunctional requirements are important, the design of functional requirements is where the true value is to the designer or end user. Thus, the engineer would prefer to focus on functional requirements (equipment control, product flow control, and so forth) providing direct improvements in value rather than dealing with superfluous technology issues.
In another case, system design does not sufficiently enable trade-offs between overhead burden (memory footprint, CPU (central processing unit) cycles, and so forth) and application coupling. For instance, processing load should be distributed across the system in accordance with system capabilities. Thus, if one part of the system is shut down, alternative processing capability should be in place to allow production to continue. For example, control and process engineers can initially design and install a control system suiting their immediate needs. Current solutions however do not facilitate a smooth and uncomplicated transition for the respective changes. Multiple technologies underneath many vendors' products complicate configuration and management of systems. This is also aggravated when third party systems are involved. Such complexity hinders the system's capacity to provide higher-level information and can reduce the ability to configure such systems.